home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / mmdf / mmdf43_docs / review / p5 < prev    next >
Encoding:
Text File  |  1986-02-01  |  2.1 KB  |  46 lines
  1. .SH
  2. Deliver
  3. .PP
  4. The \fBdeliver\fR process changed little until late 1984,
  5. when a dead-host caching facility and advanced retry mechanisms
  6. were added to \fBdeliver\fR.
  7. Until then, the major changes to \fBdeliver\fR were
  8. bug fixes and changes to enhance error recovery.
  9. Most notably, the mechanism to return mail was made much more persistent.
  10. In MMDFI, if a message could not be returned to the sender, it
  11. was ``dropped on the floor''.  This is not acceptable.
  12. The new mechanism first tries to return to the sender; if that fails,
  13. an attempt is made to send the message to the local ``Postmaster''
  14. address.  If this too fails, then \fBdeliver\fR tries to write the message
  15. into a ``dead letter'' file
  16. (usually /usr/mmdf/lock/home/DeadLetters).
  17. The last resort is to scream loudly into the log files.
  18. .PP
  19. The recent changes to \fBdeliver\fR are
  20. designed to reduce \fBdeliver\fR's load
  21. on a system that handles a large amount of mail.
  22. The first change is to move the dead-host caching function out
  23. of the channels (currently only SMTP) and into \fBdeliver\fR.  This has
  24. two advantages.
  25. First, \fBdeliver\fR no longer has to hand every address to
  26. the channel to find out that the host is dead.  This was expensive, since
  27. communications between \fBdeliver\fR and the channel
  28. are interactive using pipes
  29. and thus involved a great deal of context-switching and pipe I/O.
  30. Second, the dead-host caching is now a generally available facility that
  31. can be used by any channel without duplication of code.
  32. .PP
  33. The second change is to add a mechanism for storing the retry history
  34. for each dead host on each channel including retry count and last retry
  35. time.
  36. From this information it is possible to implement intelligent
  37. retry strategies using exponential backoff and maximal retry times.
  38. This greatly reduces the overhead caused by recalcitrant hosts
  39. that are unavailable over a long period of time.
  40. The retry history change is conditionally compiled
  41. into deliver since it can,
  42. by design, use quite a bit of memory if there are a lot of dead
  43. hosts or pending messages (or both!).
  44. Machines with a relatively limited address space may not
  45. be able to use this feature.
  46.